[レポート] Amazon EMR ServerlessでSparkのワークロードを最適化する方法について学んできました #AWSreInvent #ANT339

福岡オフィスのyoshihitohです。

今回はEMR Serverlessについてのチョークトークに参加してきました。過去に参画していたプロジェクトではEMR on EC2を利用することが多く、EMR ServerlessやGlue Jobとどうやって使い分けるんだろう？と疑問に思っていましたが、このセッションでなんとなくイメージを掴めた気がします。

それではセッション内容のレポートに入ります。

セッション概要

タイトル

ANT339 | Optimizing Apache Spark workloads with Amazon EMR Serverless

概要

Enterprises aim to build comprehensive data platforms that serve their data engineering divisions. Discover how AWS customers simplify infrastructure complexities, scale swiftly, and build fault-tolerant multi-AZ Apache Spark and Apache Hive applications with Amazon EMR Serverless. This chalk talk dives deep into how AWS customers bring the reliability of SQL to big data using open table formats such as Apache Iceberg and enforce fine-grained access controls with AWS Lake Formation.

※以降は意訳です

企業はデータエンジニアリング部門に貢献する包括的なデータプラットフォームの構築を目指しています。AWSの顧客がAmazon EMR Serverlessを活用することでどのようにインフラ構成の複雑さを簡素化し、迅速なスケールを実現し、耐障害性が高いマルチAZなApache Spark・Apache Hiveアプリケーションを構築しているかご覧ください。このチョークトークでは、AWSの顧客がApache Icebergのようなオープンテーブルフォーマットを活用することでビッグデータにSQLの信頼性をもたらし、AWS Lake Formationを使用してきめ細かいアクセス制御を実現する方法について深く掘り下げます。

スピーカー

• Behram Irani
• Karthik Prabhakar
• Ozcan ILIKHAN (Godaddy)

セッション内容

EMR Serverlessの新機能についての説明や、よくある使い方、GoDaddy社の実際の事例について紹介されていました。EMR Serverlessを使うとなぜコストを削減できるのか、その他にどのようなメリットがあるのかなど非常にわかりやすく解説されていました。

アジェンダは以下のとおりです。

1. EMR Serverlessと新機能について
2. Apache Spark最適化のためのEMR Serverlessの機能について
3. 一般的な利用パターンについて
4. カスタマーサクセスストリー (GoDaddy社の事例)

Amazon EMRとAmazon EMR Serverlessについて

Amazon EMR

Amazon EMR Serverlessについて触れる前に、まずAmazon EMRの特徴について紹介されていました。

• 最新版のツール・フレームワークを利用できる
• 低コストで最高のパフォーマンスを実現できる
• Amazon S3をストレージとして利用できる
• 簡単に利用できる

その他にも色々便利な機能や特徴があるので、詳しくはEMRの製品紹介ページを確認してみてください。

Amazon EMR Serverless

Amazon EMR Serverlessについても同様に特徴が紹介されていました。

• クラスタとサーバーを管理することなく、Amazon EMRのすべての特徴を享受できる
• フレームワークとそのバージョンを選択するだけで実行できる
• 自動でスケールするため、クラスタサイズを予測する必要が無い
• コスト最適化。自動できめ細かくスケールするためコスト削減できる
• パフォーマンスに最適化したバージョンだと2倍の性能を発揮できる
• リリース直後からマルチAZ (で高い耐障害性を実現してる)
• Apache AirflowやAWS Step Functionsといった使い慣れたツールと統合できる

扱うデータによると思いますが、時間の経過とともにデータの規模が大きくなっていくことが多いと思います。クラスタとサーバー管理無しでEMRを動かせて、更に自動でスケールしてくれるというのは非常に魅力的ですね。

Amazon EMR Serverlessの新機能

新機能についても紹介されていました。

• AWS Graviton2に対応
• CloudWatchがアプリケーションキャパシティとジョブメトリクスに対応
• EMR Studioがインタラクティブなノートブックに対応
• ジョブ単位のコスト可視化
• AWS Secrets Manager統合機能
• カスタムイメージに対応
• 大容量CPU/メモリに対応
• AWS Step Functionsに最適化した統合機能

使っているライブラリにもよりますが、Sparkアプリケーションは比較的簡単にGraviton2環境で動かせそうです。ジョブ単位のコスト可視化も意図せぬコスト増加に気づきやすくなると思うので積極的に活用していきたいです。

SparkアプリケーションがAmazon EMR Serverless上でどのように動くのか

Apache AirflowやAWS Step Functionsなど、色々な環境からSparkアプリケーションを起動することができます。Sparkアプリケーション(jarファイル・Pythonスクリプト)を送信すると、Amazon EMRのサービスアカウントでSparkアプリケーションが起動して、そこから利用者側のアカウント内のリソース(S3やRDSなど)のデータにアクセスする構成となっているようです。

Amazon EMR ServerlessにおけるGraviton2サポート

x86環境で動かす場合と比べて、以下のような改善を見込めるとのことです。

• パフォーマンスが最大で15%改善する
• 利用費が20%安くなる
• コストパフォーマンスが最大で35%向上する

EMR Serverlessではまだ確認できていませんが、EMR on EC2でx86からGraviton2に移行したときにはほぼ説明通りの改善を確認できました。EMR Serverlessでも同様の効果が見込めるというのも納得です。

カスタムイメージサポート

EMR Serverlessではアプリケーションの実行に必要なライブラリや実行環境をセットアップしたカスタムイメージを利用できるとのことです。セッションでは以下の内容で紹介されていました。

• (ScalaやPythonの)依存ライブラリをカスタマイズして組み込む
  • 既定のバージョンだと動作に問題が生じる場合、任意のライブラリを最新版にしたりダウングレードしたり、といった使い方が紹介されていました
• C++ライブラリなど、コンパイル済みの依存ライブラリをイメージに組み込む
• 既存のDockerイメージ作成プロセスを再利用してCI/CDする
• 本番環境用のゴールデンイメージを作成して運用する
• Hive UDFのjarを含めて高速化する

個人的には依存ライブラリのカスタマイズが非常に便利なように感じました。ランタイム側で用意したライブラリをアプリケーションから利用する場合、バージョンが変わるとアプリケーションが動作しなくなることがありました。このような場合に任意のライブラリを問題ない範囲で変更できると暫定対策しやすくなるので運用面で助かることが多そうかなと思います。

また、C++ライブラリなどの依存ライブラリを手軽に組み込めるという特徴も気になりました。これを活用すると Gluten/Velox や blaze/DataFusion といった他のエンジンを気軽に試せるのかもしれません。

大容量CPU/メモリサポート

ワーカーでより多くのCPU/メモリを利用することで、多くの計算処理とシャッフルを必要とするワークロードに対応できるようになりました。

• 8 vCPUs, 60GB memory
• 16 vCPUs, 120GB memory

以前、外部のシステムやサービスが出力したデータを取り込む際にファイル数や各ファイルのサイズを調整できず、1コアあたりに割り当てるメモリサイズを増やしたりシャッフルで対処するケースがありました。こういったケースにも対応しやすくなりそうですね。

一般的な利用パターン

バッチ処理

リアルタイム分析

バッチ処理について以下のような質問が出ていました。

• EMR ServerlessとGlue Jobはどう違うのか、どう使い分ければ良いのか
  • EMR (Serverless)はSparkに特化したものではない
    • Hiveクエリを実行できる
  • Sparkだけ実行するのであればGlue Job or EMR Serverlessで用途にあったものを選択する
• EMR ServerlessとEMR on EC2はどう違うのか、どう使い分ければ良いのか
  • オートスケーリングの速度に違いがある
  • EMR on EC2ではEC2のプロビジョニングが必要なため相対的に時間が長くなる
  • EMR Serverlessの場合はより迅速にスケールできる

どちらの質問もなるほどなという感じの内容でした。DynamicFrameのようなGlue固有の機能を使いたい場合はGlue Jobを、EMRの特徴を利用したい場合はEMR Serverlessを、といった感じの棲み分けでしょうか。

EMR ServerlessとEMR on EC2の比較はオートスケーリング以外にも、EC2のRIやSPの有無、スポットインスタンスの利用状況など他にも検討する内容が多そうな印象でした。

カスタマーサクセスストリー (GoDaddy社の事例)

GoDaddy社はEMR Serverlessを活用することでコストを60%以上削減できたようです。

以下のアジェンダで進行されていました。

• GoDaddy社について
• バッチ処理の状況について理解する
• EMR Serverlessに切り替えた場合のベンチマークについて
• 結果について

GoDaddy社について

GoDaddy社はドメインレジストラ・レンタルサーバーサービスを提供する米国の企業です。詳しくは公式サイトでご確認ください。

※スライドのメモ・写真を取りそこねてしまいました。。動画・スライドが公開され次第追記します。

バッチ処理の状況について理解する

Sparkアプリケーションの構成と、既存のジョブ(EMR on EC2)について分析した内容について紹介されていました。

Sparkアプリケーションの構成については、コード・設定ファイルなどにレイヤ分けした上で、EMR Serverlssへの置き換えで改善が見込める部分とそれ以外の部分を明確にしていました。

また、現状のEMR on EC2で実行するジョブ毎に所要時間を計測して現状の課題を整理した上でEMR Serverlessへの置き換えが有効と判断されたようです。

現状の理解・課題の整理・対処方法の妥当性の検証と、文字に起こすと当たり前の事にように感じるかもしれませんが実際にこれらを丁寧にこなすのは大掛かりな作業だったんじゃないかなと思います。

EMR Serverlessに切り替えた場合のベンチマークについて

EMR Serverlessへの移行で実行時間・利用費の削減を見込めるため以下の方法でベンチマーク測定されていました。

1. データと環境を用意する
2. EMR on EC2とEMR Serverlessの両方で動作確認する
3. 両者を比較しデータ処理内容が正しいか検証する
4. メトリクスと分析結果を収集する

EMR Serverlessへの移行に加えて、実行環境のアーキテクチャを x86_64からGraviton2に移行した場合についても検証されていました。GoDaddy社がEMR Serverlessを利用した場合、Graviton2を利用することで 23.8% コストパフォーマンスが向上したとのことです。

結果について

EMR Serverlessの切り替えにあたって、ジョブの影響範囲や難易度別に分けて段階的に適用されたようです。

EMR Serverlessを採用した結果、以下の改善結果となっていました。

• パイプラインごとのコストは平均で62.5%削減となった (min 8.2%、max 99.3%)
• パイプラインごとの実行速度は平均で50.4%平均で50.4% 高速化した (min 3.7%、max 97.8%)
  • DAGの実行時間は平均で18.7分短縮した (min 2.2分、max 172分)

短時間のジョブで特に改善効果が目立っていたようです。以下、EMR Serverless採用前後の利用費のグラフです。

今まで構築してきたデータパイプラインでは最初のフェーズで大量のデータを取り込み、そこから必要な項目の選定や集計を行うケースが多かったので、ジョブごとに実行時間にばらつきがあるというのはイメージしやすかったです。EMR Serverlessのオートスケールが早いという話だったのでその効果かな？と思いながら聞いていましたが、グラフで見ると想像してた以上のコスト削減効果で驚きました。

終わりに

EMR Serverlessの事例ってどんなのがあるのかな、ぐらいの軽い気持ちで参加したセッションだったんですが非常に学びの多い内容でした。EMR Serverlessはオートスケーリングの速さが大きな強みになりそうなことを学べて良かったです。また、GoDaddy社の事例ではEMR Serverlessへの置き換え効果はもちろんのこと、移行にあたってのプロセスや分析手法も学びになりました。

本セッションに参加してEMRおよびEMR Serverlessについて何も理解していないことがよくわかったので、色んな機能を試していこうと思います！